11.sol

NFT Creation and ERC721 Integration in Solidity

In this Solidity example, we demonstrate how to create and manage NFTs (Non-Fungible Tokens) using custom contracts, while also utilizing ERC721 standards and imports.

1. Imports:

   • ERC721: Imported from OpenZeppelin’s library, this standard is used for creating NFTs.
   • MyLoop: A custom import (assumed to handle looping logic).

2. NFT Contract:

   • The NFT contract creates individual NFTs by assigning a name and a unique identifier dna.
   • These NFTs are objects with custom metadata.

3. MyImport Contract:

   • Inherits from ERC721 and MyLoop.
   • Stores an array of NFT objects (nfts).

4. Key Functions:

   • addNft: Allows users to create a new NFT object with a name and DNA and stores it in the nfts array.
   • myHashedName: Returns a hashed version of any input name using keccak256 for secure identification.

5. Other State Variables:

   • myName and myBytesName: Demonstrates string and bytes handling in Solidity, where myBytesName stores a fixed-length bytes32 value.

Takeaways:

• ERC721 ensures the NFT is compatible with industry standards.
• Custom NFT logic can be built on top of the ERC721 template.
• Handling secure hashing of data using keccak256.

12.sol

Simple Loop

13.sol

Mapping and Minting NFTs in Solidity

This Solidity example demonstrates the use of mappings to manage ownership of NFTs and how to mint new NFTs.

1. Mapping Usage:

   • nfts: A mapping that links each NFT’s unique ID (a uint256) to its owner’s address (address).
   • This is a common structure to track ownership of assets in a blockchain context.

2. Functions:

   • getOwnerOfNFT:

     • This function allows anyone to query the owner of a specific NFT by its ID.
     • It takes the NFT’s ID (_id) as an argument and returns the address of the owner.

   • mintNFT:

     • This function mints a new NFT by assigning ownership to the address passed in as _address.
     • It uses a counter to automatically assign a unique ID to each newly minted NFT, ensuring each NFT has a distinct identifier.
     • After minting, the counter is incremented, ensuring that the next minted NFT gets the next available ID.

3. Takeaways:

   • Mapping: Efficiently stores and retrieves ownership information.
   • Minting Mechanism: Dynamically assigns IDs to newly minted NFTs and maps them to their owners.
   • The system automatically tracks ownership and provides an interface for users to query who owns each NFT.

14.sol

Solidity Modifiers for Access Control and Contract State Management

In this Solidity example, we explore how to use modifiers for access control and contract state management, such as pausing contract functions and restricting access to the contract owner.

1. State Variables:

   • myNum: A uint256 variable that starts at 0 and is modified by contract functions.
   • paused: A bool indicating whether the contract is paused, preventing certain actions.
   • owner: The address of the contract owner, set during contract creation.

2. Modifiers:

   • isNotPaused:

     • This modifier ensures that specific functions cannot be executed if the contract is paused.
     • It accepts a _bypass parameter. If _bypass is true, the modifier checks if paused is false and throws an error if the contract is paused. This provides flexibility, allowing different behavior for different functions.

   • onlyOwner:

     • Restricts access to the contract’s owner by requiring that the caller’s address matches the owner’s address.

3. Functions:

   • setPaused: Pauses the contract by setting paused to true, preventing functions protected by the isNotPaused modifier from being executed.

   • addToNum: Increments myNum by 1, but only if the contract is not paused and the caller is the owner.

   • sunFromNum: Decrements myNum by 1. Unlike addToNum, it can be executed even when the contract is paused due to the false value passed to the isNotPaused modifier.

4. Takeaways:

   • Modifiers streamline the enforcement of conditions like access control and state checks.
   • isNotPaused shows flexibility in using parameters within modifiers to allow or restrict function execution based on contract state.
   • onlyOwner ensures only the owner can modify critical state variables.

15.sol

Simple operators

16.sol

Handling Ether Transfers in Solidity Using Payable Functions

This Solidity example demonstrates how to manage Ether transfers, deposits, and contract balance checks using payable functions.

Key Concepts:

1. Payable Address:

   • myAddress: A payable address that can receive Ether. It’s set to the address of the contract deployer during initialization using msg.sender.

2. Functions:

   • deposit:

     • A simple payable function that allows users to send Ether to the contract. Since the function has no logic, it just accepts any incoming Ether.

   • getThisContractsBalance:

     • This view function returns the balance of Ether stored in the contract using address(this).balance.

   • transferEth:

     • Transfers the exact amount of Ether sent with the transaction (msg.value) to the _user address using the built-in transfer function. It forwards the gas stipend (2300 gas) and throws an error if the transfer fails.

   • sendEth:

     • Uses send to transfer Ether, but checks whether the operation was successful by capturing the return value (bool didSend). It reverts the transaction if sending fails.

   • callEth:

     • Uses the low-level call function to transfer Ether, which is more flexible but requires manual checking of the result. This method returns a boolean didSend, and reverts the transaction if the call fails.

3. Special Functions:

   • receive:

     • A function that automatically accepts Ether sent to the contract without any data. It ensures the contract can accept plain Ether transfers.

   • fallback:

     • This function is called when Ether is sent to the contract with data or when a function call doesn’t match any existing function. It allows the contract to receive Ether under any circumstances.

Takeaways:

• Payable Functions: Allow Ether to be sent and handled within the contract.
• Transfer Mechanisms: Solidity provides three ways to transfer Ether (transfer, send, and call). Each has different levels of control and safety.
• receive and fallback: Enable the contract to accept Ether in a flexible manner without calling specific functions.

17.sol

Using Structs to Manage NFTs in Solidity

This Solidity example demonstrates how to define and manage complex data structures using structs. In this case, a struct represents an NFT with fields for its name and DNA.

Key Concepts:

1. Struct Definition:

   • NFT Struct: Represents an NFT with two properties:
     • name: A string representing the name of the NFT.
     • dna: A uint256 that uniquely identifies the NFT’s DNA.

2. Functions:

   • addNFT:

     • Creates a new NFT instance in memory and adds it to the nftList array using the push() method.
     • Demonstrates how to initialize a struct in a single line.

   • addNFTS:

     • Accepts an array of NFT structs (using calldata for gas efficiency) and sets it as the contract’s nftList.
     • This batch function allows adding multiple NFTs at once.

   • updateNFTStorage:

     • Modifies an existing NFT’s name directly in storage by accessing the struct via its index. Using storage modifies the data in the permanent state.

   • updateNFTMemory:

     • Loads the NFT into memory (temporary data storage) and modifies it, but then updates the nftList explicitly.
     • This approach is less efficient than directly using storage and requires a reassignment to apply the changes.

   • getNftName:

     • A simple view function that returns the name of an NFT based on its index in the nftList.

Takeaways:

• Structs allow grouping related data types into a single unit.
• Storage vs. Memory: Direct updates to struct elements in storage are more gas-efficient compared to modifying a memory copy.
• Calldata: Using calldata in function arguments is optimal for read-only operations involving arrays or structs, as it saves gas compared to copying to memory.

reference.sol

Understanding Ether Units and Time Units in Solidity

This Solidity example demonstrates the use of built-in units for handling Ether and time.

Key Concepts:

1. Ether Units:

   • Solidity provides convenient units for handling Ether values:
     • 1 wei: The smallest unit of Ether, equivalent to 1.
     • 1 gwei: Equal to (10^9) wei.
     • 1 ether: Equal to (10^{18}) wei, used for larger amounts of Ether in contracts.
   • Example:
     • costOfNFT = 0.05 ether: This sets the cost of an NFT to 0.05 Ether, which is automatically converted to wei.

2. Time Units:

   • Solidity also provides built-in units for time:
     • 1 second: The basic unit of time.
     • 1 minute: Equal to 60 seconds.
     • 1 hour: Equal to 60 minutes.
     • 1 day: Equal to 24 hours.
     • 1 week: Equal to 7 days.
   • Example:
     • levelUpRate = 1 hours: This sets the rate for leveling up to 1 hour, meaning you can use this variable in time-based conditions.

Takeaways:

• Ether Units simplify handling different amounts of Ether within the contract by automatically converting them into wei.
• Time Units allow easy specification of time intervals, making it convenient to work with deadlines, cooldowns, or time-based logic.